home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-frnetmib-virtual-sma-01.txt
< prev
next >
Wrap
Text File
|
1993-07-08
|
43KB
|
1,231 lines
Draft Service Management Architecture June 1993
Service Management Architecture
for Virtual Connection Services
July 1, 1993
Frame Relay Service MIB (frnetmib) Working Group
Kenneth R. Rodemann
AT&T Bell Laboratories
krr@qsun.att.com
1. Status of this Memo
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of
six months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not
appropriate to use Internet Drafts as reference material or
to cite them other than as a "working draft" or "work in
progress."
Please check the I-D abstract listing contained in each
Internet Draft directory to learn the current status of this
or any other Internet Draft.
Rodemann Expires Jan 1, 1994 [Page 1]
Draft Service Management Architecture June 1993
2. Abstract
This document presents the Service Management Architecture,
an architectural framework for defining SNMP MIB modules for
Customer Network Management (CNM) of network services over
connection-oriented networks. The work is motivated by the
fundamental differences in management views and
functionality between a service provider and a service
customer. Differences between service provider and service
customer include whole-network vs. network-portion view,
direct vs. indirect management, and physical vs. logical
view. These fundamental differences suggest a difference in
philosophy between Service Management and Device Management.
Much work has been done and experience gained in writing
Device MIB modules for hands-on management of physical
devices, but defining Service MIB modules is a relatively
new area and requires the development of a new architectural
framework.
Rodemann Expires Jan 1, 1994 [Page 2]
Draft Service Management Architecture June 1993
3. Introduction
This document presents the Service Management Architecture,
an architectural framework for defining SNMP MIB modules for
Customer Network Management (CNM) of network services over
shared networks. Network providers offer a myriad of
network services, such as X.25, SMDS, Frame Relay, and ATM.
Some of these provide connection-oriented service, while
others provide connectionless service. CNM services are
becoming an important extension of these transport services
to provide customers with a management window into their
portion of the shared service. This document focuses on an
SNMP-based architectural framework for CNM of
connection-oriented network services.
The purpose of this work is to identify the notion of a
Service MIB module, and to define an architectural framework
for its definition that will permit easy extensibility and
interoperability across various network services. In order
to explore and understand how Service and Device management
differ, consider the following fundamental differences in
network management functionality between a network service
provider and a service customer.
First, service providers are responsible for managing the
entire shared network as a whole, while service customers
only view and manage their individual portions of the shared
service. Because they have a restricted view of the
network, customers are unable to perform certain network
management functions in the shared environment. For
example, a customer which sets routes for optimized
throughput of their own traffic may disrupt another
customer's traffic. Only the service provider, with a
complete view of the entire network, is in a position to
determine routes that allow provisioned access to network
resources for all customers.
A second fundamental difference in management functionality
is that service providers manage the network internals
directly, while customers manage their portion of the shared
network indirectly. The service provider is responsible for
the overall operation of the shared network, so any
management control offered to customers must first be
approved (perhaps manually) by the service provider before
the control request takes effect in the network.
Rodemann Expires Jan 1, 1994 [Page 3]
Draft Service Management Architecture June 1993
Finally, while service providers see a physical view of the
network, customers see a logical view. This logical view
includes the customer's configuration of service access
points (logical ports) and the virtual connections that run
between these logical ports. The customer does not see the
individual network switches along the paths of its virtual
connections---setting up physical routes is a responsibility
of the service provider.
These fundamental differences in network management
functionality suggest that there is a wholly different
philosophy between Service Management and Device Management.
A Device MIB module allows for hands-on management of a
physical entity. A Service MIB module provides to customers
a logical view of the customer's portion of a shared network
service by modeling the service, not the underlying
implementation or devices. Much work has been done and
experience gained in writing Device MIB modules for hands-on
management of physical devices, but defining Service MIB
modules is a relatively new area and requires the
development of a new architectural framework.
Rodemann Expires Jan 1, 1994 [Page 4]
Draft Service Management Architecture June 1993
4. Service Architecture
A connection-oriented network service offered by a service
provider can be viewed as a logical configuration of service
access points (logical ports), access channels, and virtual
connections (see Figure 1). Note that the term is used
instead of 'interface' to distinguish between a service
access point and a physical device access point.
+---------------------+
| |
###@=====================@###
|\ |
| =================== |
| \|
| @###
| /|
| =================== |
|/ |
###@=====================@###
| |
+---------------------+
Where @ is a service access point (logical port)
### is an access channel
=== is a virtual connection through
the service provider's network
Figure 1:
Logical view of a connection-oriented network service,
including service access points (logical ports),
access channels, and virtual connections.
The service provider manages the internals of the network
(switch and trunk acquisition/placement, virtual connection
provisioning/routing, internal fault detection/correction,
etc.), so the service customer need not be concerned with
such aspects. Instead, the service customer views and
indirectly manages the components in its logical view of the
service offering.
Rodemann Expires Jan 1, 1994 [Page 5]
Draft Service Management Architecture June 1993
A customer may subscribe to the services of more than one
service provider, with end-to-end virtual connections that
span multiple service providers' networks. These
multi-segment virtual connections can be viewed as a
concatenation of individual service-provider views (see
Figure 2).
+---------+ +---------+ +---------+
| Service | | Service | | Service |
| Provider| | Provider| | Provider|
------+ | A | | B | | C | +------
| | | | | | | |
Cust |###@=========@###@=========@###@=========@###| Cust
| | | | | | | |
------+ | | | | | | +------
+---------+ +---------+ +---------+
Figure 2:
Logical view of a customer's end-to-end
virtual connection that spans across
multiple service providers' networks.
The end-to-end view is a concatenation
of individual service-provider views.
The next section discusses the Service Management
Architecture, modeled upon the service architecture just
presented.
Rodemann Expires Jan 1, 1994 [Page 6]
Draft Service Management Architecture June 1993
5. Service Management Architecture
We previously discussed fundamental differences in network
management functionality between a service provider and a
service customer. These fundamental differences led to a
distinction between a Device MIB module and a Service MIB
module. A Service MIB module models the offered service, so
we now apply the preceding Service Architecture to derive a
generic Service MIB Module Architecture.
There exist two views of virtual connections within the
Service Architecture: service-provider views and customer
end-to-end views. Service-provider views consist of
single-segment virtual connections established through a
single service provider's network. Customer end-to-end
views consist of multi-segment end-to-end virtual
connections that span across multiple service providers'
networks. This end-to-end view represents a multi-segment
virtual connection as a concatenation of individual
service-provider segments. We first consider the
service-provider view, then briefly outline the customer
end-to-end view.
5.1 Service-Provider View
The Service Architecture identifies three types of service
objects within the service-provider view: service access
points (logical ports), access channels, and virtual
connections. A customer's logical configuration of service
objects can be defined in generic terms, regardless of the
underlying datalink protocol (X.25, Frame Relay, ATM, etc.)
of the service offering. Defining the configuration in such
a protocol-independent fashion will give to customers a
consistent end-to-end view of interworking services.
5.1.1 Logical Port Table Structure
This document follows the recommendations of the Internet
Draft, "Evolution of the Interfaces Group of MIB-II" [1],
which proposes that each layer in an interface's protocol
stack have its own entry in the Interfaces Table, and the
hierarchical relationships between interface layers are
given in the new ifStack Table. Because the access channel
is layered "below" the logical port, the logical port and
the access channel each have their own ifTable entry and
ifIndex.
Rodemann Expires Jan 1, 1994 [Page 7]
Draft Service Management Architecture June 1993
Consider the example given in Figure 3 of a typical Frame
Relay interface stack. This interface stack is represented
by two entries in the ifTable, one for the physical layer
(DS1) and one for the Frame Relay layer. The ifStackTable
gives the layering relationship between these two ifTable
entries. Of course, there may be other layers involved; for
example, a Frame Relay service may run over an ATM service,
which itself runs over a physical layer. Note that since the
Frame Relay service is modeled as a single entity, each
logical port's ifIndex value is unique within the service
provider's offering.
Interfaces Table
================
ifIndex ifType
+--------------------------------------------------------+
| : | | | |
| : | | | |
| 50 |......| XX (FR Network Service) | ....... |
| : | | | |
| 74 |......| 18 (DS1) | ....... |
| : | | | |
| : | | | |
+--------------------------------------------------------+
ifStack Table
=============
ifStackHigherLayer ifStackLowerLayer
+--------------------------------------------+
| : | : |
| 50 | 74 |
| : | : |
+--------------------------------------------+
Figure 3:
Example Interfaces and ifStack Table entries for
a Frame Relay Network Service over DS1.
Rodemann Expires Jan 1, 1994 [Page 8]
Draft Service Management Architecture June 1993
The ifTable contains entries for logical ports of various
service protocols (for example, Frame Relay logical ports
and ATM logical ports). Each of these network services are
described in a protocol-specific MIB module that contains a
logical port table indexed by the ifIndex of the associated
ports. The ifSpecific variable of a logical port's
Interfaces Table entry points to the associated
protocol-specific logical port table. That table, in turn,
may contain pointers to other protocol-specific tables, such
as a link management table.
There are a number of other ifTable variables that may apply
to the network service logical port. When defining a
protocol-specific MIB module, that module definition should
define the proper use for each of these ifTable variables.
Figure 4 shows an example table structure for a Frame Relay
logical port. In the figure, the Interfaces Table entry for
the port contains a pointer to the logical port's
Frame Relay-specific table. This entry in turn contains a
pointer to the proper link management MIB table for that
logical port.
5.1.2 Virtual Connection Table Structure
Virtual connections are logical data transport connections
between a pair of logical ports. Within the Service
Management Architecture, the MIB table structure for virtual
connection tables is similar to the structure for logical
ports. All virtual connections, regardless of protocol
type, are placed in a protocol-independent VC table, and
each entry in the VC table contains a pointer to the
associated entry in a protocol-specific virtual connection
table. Note that this pointer points to an actual *entry*
in the protocol-specific table, not just the top of the
table. This is necessary because the protocol-specific VC
table may be indexed differently than the
protocol-independent VC table.
The protocol-independent VC table contains two entries for
each virtual connection---one entry for each endpoint of the
VC. Each endpoint is separately identified and indexed by a
tuple (logical port ifIndex, VC id), where the VC id is a
logical identifier unique to the associated logical port.
This VC id is assigned by the service provider as it sees
fit. The service provider *may* map the VC id directly to
Rodemann Expires Jan 1, 1994 [Page 9]
Draft Service Management Architecture June 1993
Frame Relay
Interfaces Frame Relay link mgmt
Table logical port table table
+-----------------+ +-----------------+ +------------+
| ifIndex=50 | -->| portIndex=50 | -->| lmIndex=50 |
|-----------------| | |-----------------| | |------------|
| . | | | : | | | : |
| : | | | : | | | : |
|-----------------| | |-----------------| | +------------+
| ifType=XX | | | associated | |
|(FR Network Srv) | | | link mgmt OID -+--
|-----------------| | |-----------------|
| . | | | : |
| : | | | : |
|-----------------| | +-----------------+
| ifSpecific OID -+--
+-----------------+
Figure 4:
Example Service Management Architecture table
structure for a Frame Relay logical port.
the addressing scheme used in the underlying protocol (e.g.,
DLCI for Frame Relay), but this is not necessary.
The set of variables contained in a given row in the VC
table describe the virtual connection's attributes as viewed
from the endpoint identified by the row's indexing tuple
(see Figure 5). To correlate the opposite endpoints of a
given virtual connection, each endpoint row in the VC table
references the other end's row via two variables that
contain the remote end's logical port ifIndex and VC id.
Variables associated with the remote end of a given table
entry can be retrieved by indexing the VC table on the
values of remote logical port ifIndex and remote VC id.
Thus, the complete set of attributes for a virtual
connection are contained in the aggregation of that
connection's two table entries.
Rodemann Expires Jan 1, 1994 [Page 10]
Draft Service Management Architecture June 1993
+---------------------+
| |
| |
| |
ingress ---> | | <---- ingress
if1| VC1 VC1 |if2
###@=====================@###
egress <---- I | ----> egress
| |
| |
| |
| |
+---------------------+
PROTOCOL-INDEPENDENT VIRTUAL CONNECTION TABLE
(indexed on local ifIndex/local VC id)
=============================================
local local remote remote
ifIndex VC id ifIndex VC id In vars Out vars
+---------------+---------------+---+-------+---+-------+
| 1 | 1 | 2 | 1 |...| |...| |
| 2 | 1 | 1 | 1 |...| |...| |
| : | : | | | | | | |
+---------------+---------------+---+-------+---+-------+
Figure 5:
Endpoint views for protocol-independent virtual
connection table, and the associated table entries.
Note that the protocol-independent virtual connection table
described above does not yet exist as a part of MIB II. We
therefore propose that a Virtual Connection Group defining a
new table called vcTable be added to the ifMIBObjects MIB
branch defined in [1].
Rodemann Expires Jan 1, 1994 [Page 11]
Draft Service Management Architecture June 1993
This document proposes an initial set of objects for this
table as follows:
+ local logical port ifIndex
+ local VC id
+ remote logical port ifIndex
+ remote VC id
+ VC status info
+ Ingress Octets
+ Ingress Packets
+ Egress Octets
+ Egress Packets
+ reference to (OID of) protocol-specific virtual
connection MIB entry
The vcTable contains an OID that points to associated
entries in protocol-specific tables. To allow for management
of interworking service objects, the reverse references must
also be in place, i.e., references from the
protocol-specific tables to entries in the vcTable. These
backward references may be either OIDs or indexes into
vcTable.
Figure 6 shows how to use vcTable with an associated
protocol-specific virtual connection table.
proto-specific
vcTable VC table
+-----------------+ +------------+
| local ifIndex | -->| proto-spec |
|-----------------| | | VC table |
| local VC id | | | indexes |
|-----------------| | |------------|
| : | | | : |
| : | | | : |
|-----------------| | |------------|
| proto-specific | | | vcTable |
| VC entry OID -+-- | back ref |
+-----------------+ +------------+
Figure 6:
Service Management Architecture vcTable and associated
protocol-specific virtual connection table relationship.
Rodemann Expires Jan 1, 1994 [Page 12]
Draft Service Management Architecture June 1993
5.1.3 Example
The following shows an example scenario of the relationship
between ifTable, vcTable, and their associated
protocol-specific tables. The example also demonstrates how
the Service Management Architecture provides a consistent
management view of a service provider's interworking
service.
Figure 7 gives the configuration of a customer with 5
logical ports, 3 of which are Frame Relay logical ports
(lp1, lp2, lp3) and 2 are ATM logical ports (lp4, lp5). Of
the customer's 4 virtual connections, 2 are pure Frame Relay
connections, 1 is a pure ATM connection, and 1 is an
interworking connection between Frame Relay and ATM. The
customer accesses the service via two different types of
access channels, DS1 and DS3.
+---------------------+
FR lp1| VC1 VC1 |lp2 FR
DS1 ###@=====================@### DS1
|\ |
| =================== |
| VC2 VC1\|lp3 FR
| @### DS3
| VC1 VC2/|
| =================== |
ATM lp4|/ |lp5 ATM
DS3 ###@=====================@### DS3
| VC2 VC1 |
+---------------------+
Figure 7:
Example customer configuration of an interworking
service offered by a service provider. lp<n> is
a logical port with ifIndex <n>, and VC<n> is a
VC endpoint with VC id <n> on the associated
logical port. FR/ATM are the logical port-specific
datalink protocols and DS1/DS3 are the specific
physical layers.
The ifTable has 5 interface stacks (one stack per logical
port) associated with this service provider's network, as
shown in Figure 8. The vcTable has 8 entries (one entry for
each end of the 4 virtual connections), as shown in Figure
9.
Rodemann Expires Jan 1, 1994 [Page 13]
Draft Service Management Architecture June 1993
ifTable
========
ifIndex ifType ifSpecific
+----------------------------------------------+
| 1 |...| XX (FR) |...| *FR Lport table |
| 2 |...| XX (FR) |...| *FR Lport table |
| 3 |...| XX (FR) |...| *FR Lport table |
| 4 |...| YY (ATM) |...| *ATM Lport table |
| 5 |...| YY (ATM) |...| *ATM Lport table |
| 6 |...| 18 (DS1) |...| *DS1 table |
| 7 |...| 18 (DS1) |...| *DS1 table |
| 8 |...| 30 (DS3) |...| *DS3 table |
| 9 |...| 30 (DS3) |...| *DS3 table |
| 10 |...| 30 (DS3) |...| *DS3 table |
+----------------------------------------------+
FR Logical Port Table
ifStack Table =====================
=============
Lport
Higher Lower ifIndex
+---------------+ +------------------------+
| 1 | 6 | | 1 | ...... |
| 2 | 7 | | 2 | ...... |
| 3 | 8 | | 3 | ...... |
| 4 | 9 | +------------------------+
| 5 | 10 |
+---------------+
ATM Logical Port Table
======================
Lport
ifIndex
+------------------------+
| 4 | ...... |
| 5 | ...... |
+------------------------+
Figure 8:
Application of Service Management Architecture
(logical port-related tables) for the example.
Rodemann Expires Jan 1, 1994 [Page 14]
Draft Service Management Architecture June 1993
The example shows the forward and backward references
between related tables. First, consider the references for
the logical port-related tables. The forward reference
(ifSpecific in ifTable) points to the top of the
protocol-specific logical port table for the associated
logical port. The protocol-specific logical port entry has
the same index (ifIndex) as the ifTable entry. The backward
reference for the logical port-related tables is
implicit---the associated ifTable entry for a given
protocol-specific entry is found by indexing the ifTable
using the value of Lport ifIndex.
Next, consider the references for the virtual
connection-related tables. The forward reference within
vcTable points to the actual entry within the proper
protocol-specific VC table for the associated endpoint of
the virtual connection. This reference must point to the
actual entry, not the top, of the associated
protocol-specific VC table because the protocol-specific
VC table may be indexed differently than vcTable. For the
backward references, the example shows two possible methods.
The FR-specific VC table gives the vcTable's VC id, so the
associated vcTable entry is found by indexing on
(local ifIndex, vcTable VC id). The ATM-specific VC table
gives an OID pointer back to the associated vcTable entry.
Both protocol-specific VC tables also indicate if a virtual
connection is an interworking connection---with a DLCI value
of -1 for the Frame Relay module, and an interworking flag
value of 1 for the ATM module.
Finally, consider how to use these references to find the
remote end of the interworking virtual connection. From the
Frame Relay side:
The index into the FR-specific VC table is (3, 200).
The remote DLCI for this entry is -1, indicating that
this is an interworking virtual connection. The
backward reference uses the values of local ifIndex=3
and vcTable VC id=2, so indexing the vcTable on (3, 2),
we find the remote end is remote ifIndex=4 and
remote VC id=1 (4, 1). Now indexing the vcTable on
(4, 1), we find that this entry points to the first
entry in the ATM-specific table, which is the proper
protocol-specific entry for the remote end of the
virtual connection.
Rodemann Expires Jan 1, 1994 [Page 15]
Draft Service Management Architecture June 1993
vcTable
(indexed on local ifIndex/local VC-id)
======================================
OID of
table local local remote remote proto-specific
entry ifIndex VC id ifIndex VC id VC table
+-----------------------------------------------------+
1 | 1 | 1 | 2 | 1 |...| *FR VC entry 1 |
2 | 1 | 2 | 3 | 1 |...| *FR VC entry 2 |
3 | 2 | 1 | 1 | 1 |...| *FR VC entry 3 |
4 | 3 | 1 | 1 | 2 |...| *FR VC entry 4 |
5 | 3 | 2 | 4 | 1 |...| *FR VC entry 5 |
6 | 4 | 1 | 3 | 2 |...| *ATM VC entry 1 |
7 | 4 | 2 | 5 | 1 |...| *ATM VC entry 2 |
8 | 5 | 1 | 4 | 2 |...| *ATM VC entry 3 |
+-----------------------------------------------------+
FR-SPECIFIC VC TABLE
(indexed on local ifIndex/local DLCI)
=====================================
table local local vcTable remote remote
entry ifIndex DLCI VC id ifIndex DLCI
+--------------------------------------+
1 | 1 | 100 | 1 | 2 | 200 |
2 | 1 | 110 | 2 | 3 | 110 |
3 | 2 | 200 | 1 | 1 | 100 |
4 | 3 | 110 | 1 | 1 | 110 |
5 | 3 | 200 | 2 | 4 | -1 |
+--------------------------------------+
ATM-SPECIFIC VC TABLE
(indexed on local ifIndex/local VPI/local VCI)
==============================================
OID of
table local local local vcTable I/W remote remote remote
entry ifIndex VPI VCI entry flag ifIndex VPI VCI
----------------------------------------------------+
1 | 4 | 100 | 10 | *entry 6 | 1 | 3 | 0 | 0 |
2 | 4 | 110 | 10 | *entry 7 | 0 | 5 | 100 | 20 |
3 | 5 | 100 | 20 | *entry 8 | 0 | 4 | 110 | 10 |
----------------------------------------------------+
Figure 9:
Application of Service Management Architecture
(virtual connection-related tables) for the example.
Rodemann Expires Jan 1, 1994 [Page 16]
Draft Service Management Architecture June 1993
From the ATM side:
The index into the ATM-specific VC table is
(4, 100, 10). The I/W flag for this entry is 1,
indicating that this is an interworking virtual
connection. The backward-reference OID for this entry
points to the sixth entry in vcTable. We find the
remote end for the sixth vcTable entry is
remote ifIndex=3 and remote VC id=2 (3, 2). Now
indexing the vcTable on (3, 2), we find that this entry
points to the fifth entry in the FR-specific table,
which is the proper protocol-specific entry for the
remote end of the virtual connection.
5.2 Customer End-to-end View
The customer end-to-end view provides the correlating
information to view end-to-end virtual connections that span
through multiple service providers' networks. This
end-to-end view represents a multi-segment virtual
connection as a concatenation of individual service-provider
segments. The section of the Service Management
Architecture is very sketchy. An adequate definition of
this view requires much more discussion and experience.
Here is a sketchy initial stab at the information needed for
this end-to-end view. This is not in MIB format, i.e.,
having a table within a table, but this shows the type of
required information for this view. An entry in the
end-to-end MIB module may include:
+ end-to-end VC id
+ end-to-end VC status info
+ ordered list of VC Segments:
- VC Segment number
- VC Segment Provider info
- VC Segment status info
- point A logical port ifIndex
- point A VC id
- point B logical port ifIndex
- point B VC id
Note the use of generic terms "point A" and "point B". The
intent is to refrain from using terms like
Originating/Terminating and Source/Destination that suggest
a master-slave type of relationship. The only relationship
Rodemann Expires Jan 1, 1994 [Page 17]
Draft Service Management Architecture June 1993
to be inferred from the terms point A and point B is the
polarization or orientation of individual VC segments, i.e.,
point B of the i'th segment is attached to point A of the
i+1'st segment.
Rodemann Expires Jan 1, 1994 [Page 18]
Draft Service Management Architecture June 1993
6. Summary
This document presents the Service Management Architecture
for defining Service MIB modules. The work is motivated by
the fundamental differences in management views and
functionality between a service provider and a service
customer. Differences between service provider and service
customer include whole-network vs. network-portion view,
direct vs. indirect management, and physical vs. logical
view. These fundamental differences suggest a difference in
philosophy between Service Management and Device Management.
The Service Architecture models a customer's view of a
shared network service as a logical configuration of logical
ports, access channels, and virtual connections. A service
customer indirectly manages the components within its
logical view, not the internals of the shared network.
Virtual connections that span across multiple service
providers' networks are viewed as concatenations of
individual service-provider segments.
Modeled upon the Service architecture, the Service
Management Architecture presents two views of virtual
connections: service-provider views and customer end-to-end
views. Service-provider views consist of single-segment
virtual connections established through a single service
provider's network, while customer end-to-end views consist
of multi-segment end-to-end virtual connections that span
across multiple service providers' networks.
This document discusses more of the service-provider view
than it does the customer end-to-end view. The
service-provider view consists of ifTable and a new vcTable
for defining configuration, with references to
protocol-specific MIB modules. This structure provides a
clean Service Management Architecture that promotes
consistent views across various underlying implementations
and interworking of services.
Rodemann Expires Jan 1, 1994 [Page 19]
Draft Service Management Architecture June 1993
7. References
[1] McCloghrie, K., F. J. Kastenholz, "Evolution of the
Interfaces Group of MIB-II", Internet Draft, Interfaces
MIB Working Group, 1 June 1993.
Rodemann Expires Jan 1, 1994 [Page 20]
Draft Service Management Architecture June 1993
8. Security Considerations
Security issues are not discussed in this memo.
9. Author's Address
Kenneth R. Rodemann
AT&T Bell Laboratories
Room 1F-435A
101 Crawfords Corner Road
PO Box 3030
Holmdel, NJ 07733-3030
908-949-6229
krr@qsun.att.com
Rodemann Expires Jan 1, 1994 [Page 21]
Table of Contents
1. Status of this Memo................................. 1
2. Abstract............................................ 2
3. Introduction........................................ 3
4. Service Architecture................................ 5
5. Service Management Architecture..................... 7
5.1 Service-Provider View.......................... 7
5.1.1 Logical Port Table Structure 7
5.1.2 Virtual Connection Table Structure 9
5.1.3 Example 13
5.2 Customer End-to-end View....................... 17
6. Summary............................................. 19
7. References.......................................... 20
8. Security Considerations............................. 21
9. Author's Address.................................... 21
Rodemann Expires Jan 1, 1994 [Page 22]
